Motivation

Codex CLI's and Claude Code's default sandboxes deny the primitives fspy's Unix shared memory was built on. The macOS Seatbelt profile denies shm_open (#563), and both sandboxes block Unix domain sockets, which the Linux memfd broker depended on. Plain files in the temp directory work under both sandboxes; the IPC lock file lives there today.

This PR replaces all three platform backends with one file-backed implementation, mapped through memmap2 on every platform. The API has three types, each one platform concept:

• ShmKeeper is the name. create returns it, it carries the identifier (the backing file's absolute path), and dropping it removes the file with remove_file.
• ShmHandle is the opened file. create returns one, so the creator never looks its own file up by name, and open returns one to everybody else. map can be called more than once.
• Mapping is the bytes. It keeps them alive until dropped and cannot affect the name.

Removal works on every platform because modern Windows deletes with POSIX semantics: the name goes away at once, existing handles keep working, and mapped views keep the data alive. CI probes on Windows Server confirmed both, with a live writable view and with an open share-delete handle. The docs reserve the right to fail the delete while a view is mapped, and Windows versions without POSIX delete do fail it, so the keeper falls back to reopening the file with FILE_FLAG_DELETE_ON_CLOSE and closing it. Unit tests pin the full removal semantics: name gone with a live mapping, name gone with an open handle, and the handle still mapping the same bytes afterwards.

Name removal is cleanup. The channel invalidates contents inside the shared bytes, so nothing depends on removal timing. Backing files sit directly in the system temp directory as vite-task-fspy-<uuid>.shm with mode 0o600; a shared subdirectory would belong to whichever user created it first and lock everyone else out. The identifier is resolved to an absolute path at creation, so a relative TMPDIR in the creating process cannot mislead an opener with a different working directory.

There is no broker, no global object name, no tokio requirement, and no hand-written mapping code: the Windows-specific parts shrink to the sparse-file FSCTL and the creation flags.

If the keeper's process is killed, the file stays behind: on Unix for the temp reaper, on Windows until a cleanup tool runs. It costs about as much disk as the run wrote into it.

Refs #563.

🤖 Generated with Claude Code